Enterprise applications need to contact people and have requirements for how the contact is done and what responses, if any, are collected. For example, applications may need to contact all people who have certain interests, or a particular list of people or a single person. Applications may need to contact someone immediately in a crisis or they may want to remind someone of a task at an appropriate time. Enterprise applications also have requirements about what to do when the contact is unsuccessful, where success is something defined by the enterprise.
Recipients, on the other hand, have their own preferences about how and when they are contacted. For example, recipients may want particular people, such as a boss or family member, or people who represent particular interests, such as an executive from a Fortune 500 Company, to be given more flexibility in establishing real-time contact. In addition, recipients may routinely delay contact about known tasks, such as weekly status or expense updates, until a convenient time or place. Oftentimes, the preferences of recipients are at odds with the preferences of an enterprise or the implementation of a specific application. In those cases, recipients find creative ways to work around the application constraints, in order to satisfy their preferences, or find the enterprise's processes frustrating or even annoying.
A number of notification systems have been proposed or developed to enable applications to communicate with one or more recipients. U.S. patent application Ser. No. 10/184,236, filed Jun. 26, 2002, entitled “Method and Apparatus for Automatic Notification and Response;” and U.S. patent application Ser. No. 10/184,325, filed Jun. 26, 2002, entitled “Method and Apparatus for Automatic Notification and Response Based on Communication Flow Expressions,” disclose notification and response systems. Generally, the disclosed notification and response systems (i) send requests to one or more recipients, using the medium specified by each individual recipient; (ii) collect and processes responses; and (iii) forward the responses to their final destination by means of the medium specified by the final destination.
While communication flows in such notification and response systems elicit responses from recipients and may follow different paths based on a response, they can only react to responses at the point at which they were elicited or at a subsequent point. In addition, such notification and response systems are unable to dynamically add or remove participants in a communication flow.
A need therefore exists for notification and response systems that can react dynamically to responses in a variety of locations in a communication flow, different from the location that elicited the response. A further need exists for notification and response systems that can react to changes in the data of the request. Yet another need exists for notification and response systems that understand the context of the communication flow execution and make decisions that are context dependent in the communication flow and in the rendering of information to applications.